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(57) Abstract: The invention relates to a method for debugging rec< 
f^i necessary debug information for each configuration cycle is written it 



lfigurable hardware. According to the inventive method, all 
o a memory which is then evaluated by the debugger. 



(57) Zusammenfassung: Die Erfindung betrifft ein Verfahren zum Debuggen von rekonfigurierbarer Hardware. Hierbei ist u. a. 
vorgesehen, dass samtliche notwendige Debug-Information je Konfigurationszyklus in einen Speicher geschrieben wird, der dann 
^* vom Debugger ausgewertet wird. 
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ritel: Verfahren zura Debuggen rekonf igurierbarer 

Architekturen 



5 Beschreibung 

Die vorliegende Erfindung befaBt sich mit Verfahren ftir das 
Debuggen von Programmen auf konf igurierbaren Architekturen. 
Unter einer rekonf igurierbaren Architektur werden u. a. Bau- 

10 steine (VPU) mit konf igurierbarer Funktion und/oder Vernet- 
zung verstanden, insbesondere integrierte Bausteine mit einer 
Mehrzahl von ein- oder mehrdimensional angeordneten arithme- 
tischen und/oder logischen und/oder analogen und/oder spei- 
chernden und/oder vernetzenden Baugruppen (im Folgenden PAEs 

15 genannt) und/oder kommunikativen/peripheren Baugruppen (10), 
die direkt oder durch ein oder mehrere Bussystem(e) miteinan- 
der verbunden sind. PAEs sind in beliebiger Ausgestaltung, 
Mischung und Hierarchie angeordnet . Diese Anordnung wird im 
weiteren PAE-Array oder PA genannt . 

20 

Zur Gattung dieser Bausteine zahlen systolische Arrays, neu- 
ronale Netze, Mehrprozessor-Systeme, Prozessoren mit mehreren 
Rechenwerken und/oder logischen Zellen, Vernetzungs- und 
Netzwerkbausteine wie z.B. Crossbar-Schalter, ebenso wie be- 

25 kannte Bausteine der Gattung FPGA, DPGA, XPUTER, etc. Hinge- 
wiesen wird insbesondere in diesem Zusammenhang auf die fol- 
genden Schutzrechte desselben Anmelders : P 44 16 881.0-53, DE 
197 81 412.3, DE 197 81 483.2, DE 196 54 846.2-53, 
DE 196 54 593.5-53, DE 197 04 044.6-53, DE 198 80 129.7, 

30 DE 198 61 088.2-53, DE 199 80 312.9, PCT/DE 00/01869, 
DE 100 36 627.9-33, DE 100 28 397.7, DE 101 10 530.4, 
DE 101 11 014.6, PCT/EP 00/10516, EP 01 102 674.7, 
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DE 102 06 856.9, 60/317,876, DE 102 02 044.2, DE 101 29 
237.6-53, DE 101 39 170.6. Diese sind hiermit zu Offenba- 
rungszwecken vollumf anglich eingegliedert . 

5 Weiterhin soil angemerkt werden, daB die zu beschreibenden 

Verfahren auch auf Gruppen von mehreren Bausteinen angewendet 
werden konnen. Dennoch wird nachfolgend auf VPU und/oder auf 
„Bausteine" Bezug genommen. Diese Bauteile und deren Betrieb 
sind noch zu verbessern. 

10 

Die Aufgabe der vorliegenden Erfindung besteht darin, Neues 
fur die gewerbliche Anwendung bereitzustellen. 

Die Lc-sung der Aufgabe wird unabhangig beansprucht . Bevorzug- 
15 te Ausfuhrungsf ormen befinden sich in den Unteranspriichen. 



1. Erfindungsgemafies Verfahren 

20 Es werden nachfolgend mehrere Verfahren und Hardwareimplemen- 
tierungen vorgestellt, die ein effizientes Debuggen von VPU- 
Systeraen ermoglichen. 

Das Debuggen erfolgt in einer bevorzugten Variante entweder 
25 durch die Verwendung eines entsprechend an eine VPU oder den 
Baustein angeschlossenen Microcontrollers oder durch eine 
Ladelogik nach den Patenten P 44 16 881.0-53, 
DE 196 51 075.9-53, DE 196 54 846.2-53, DE 196 54 593.5-53, 
DE 197 57 200.6-33, DE 198 07 872.2, DE 101 39 170.6, 
30 DE 199 26 538.0, DE 100 28 397.7, die durch Bezugnahme 

vollumf anglich eingegliedert sind. Wie ersichtlich sein wird, 
sind aber auch andere Hardware-Varianten verwendbar. 
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Folgende grundlegende Verfahren sollen alternativ und/oder 
gemeinsam dabei angewendet werden: 



5 1.1 Erkennen einer Debug-Bedingung 

1.1.1 Bedingung 

Durch den Programmierer wird beispielsweise innerhalb des De- 
bug-Tools eine oder mehrere Bedingungen festgelegt, die das 

10 Debugging starten (vgl. Breakpoint nach dem Stand der Tech- 
nik) . Das Auftreten der Bedingungen wird zur Lauf zeit in der 
VPU und/oder einem beliebigen mit der VPU datenaustauschenden 
Gerat f estgestellt . Dies geschieht beispielsweise durch das 
Auftreten von bestimmten Datenwerten bei bestimmten Variablen 

15 und/oder bestimmten Triggerwerten bei bestimmten PAEs . 

1.1.2 Vorbedingunq 

Im Optimalfall kann eine bestimmte Bedingung gemafi o.g. Defi- 
20 nition bereits mehrere Takte vor dem Eintreffen der Debug- 
Bedingung durch den Programmierer festgelegt werden. Dadurch 
werden bestimmte Latenz-Probleme , die im folgenden diskutiert 
werden, von vornherein ausgeschlossen . 

25 Es sollen im folgenden zwei grundlegende Arten des Debuggings 
far VPUs diskutiert werden, wobei die jeweils bevorzugt anzu- 
wendende Methode von der Wahl des Compilers abhangt: 
Fur Compiler, die Code auf Basis von instantiierten Modulen 
einer Hardwarebeschreibungssprache (oder ahnlichen Sprache) 

30 generieren, kann sich besonders die im folgenden beschriebene 
Methode A eignen. 
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Fur Compiler ahnlich DE 101 39 170.6 und Zusatzanmeldungen, 
die komplexe Instruktionen erzeugen und nach einem VLIW- 
ahnlichen Verfahren generieren, eignet sich besonders die im 
folgenden beschriebene Methode B. Grundsatzlich ist fur den 
5 Betrieb einer VPU oder eines entsprechenden Bausteins als 
Prozessor oder Coprozessor Methode B die bevorzugt anzuwen- 
dende. 

Es wurde erkannt, dass insbesondere die Verwendung beider Me- 
10 thoden A und B gemeinsam zu den besten und transparentesten 
Debuggingergebnissen f iihrt . Insbesondere kann je nach Tiefe 
des zu debuggenden Fehlers zunachst unter Zuhilf enahme der 
schnellen Debuggingmethode B debuggt werden und nach hinrei- 
chende Lokalisierung des Fehlers sodann per Methode A die De- 
15 tails in der "Tiefe" analysiert werden. 

2. Methode A 

20 2.1 Groin dprin zip 

Nach dem Auftreten einer ( Vor ) Bedingung wird die VPU angehal- 
ten. Danach werden die relevanten Debug-Inf ormationen aus den 
PAEs an das Debug-Programm iibertragen. Die relevanten Debug- 
Inf ormationen wurden zuvor durch den Programmierer innerhalb 

25 des Debug-Programmes festgelegt. Nach Auslesen aller relevan- 
ter Debug-Inf ormationen wird der nachste Takt ausgefiihrt und 
erneut die relevanten Debug-Inf ormationen ausgelesen. Dies 
wiederholt sich solange, bis der Programmierer den Debug- 
Vorgang abbricht . Anstelle des Anhaltens der VPU sind eventu- 

30 ell andere Verfahren denkbar. So konnen fur eine gegebene Ab- 
folge von Takten wiederholt Daten zum Auslesen bereitgestellt 
werden, sofern dies schnell genug moglich ist. 
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2.2 Unfcerstiitzung durch die Hardware 

2.2.1 Auslesen der Register 

Wesentlich fur die Funktionsweise des Debuggers ist die Mog- 
5 lichkeit, durch eine ubergeordnete Einheit (im folgenden De- 
bugProzessor (DB) genannt) , also beispielsweise eine CT oder 
Ladelogik, einen anderen extern angeschlossenen (Host) Pro- 
zessor oder einen reservierten Arraybereich, die internen Da- 
tenregister und/oder Statusregister und/oder Zustandsregister 

10 und ggf. je nach Implementierung weitere relevante Register 
und/oder Signale aus den PAEs und/oder dem Netzwerk zuruckzu- 
lesen bzw. dies nur fur ausgewahlte Register bzw. Signale zu 
tun (zusammengefaftt im folgenden als Debuginf ormation be- 
zeichnet) . Eine derartige Moglichkeit ist z. B. mit der in 

15 der PCT/DE 98/00334 geschaffenen Verbindung zwischen der 

Ladelogik und dem Datenbus einer PAE (PCT/DE 98/00334 0403, 
Fig. 4) realisierbar . 

Es soli ausdrticklich angemerkt sein, dafi auch serielle Ver- 
20 fahren zum Auslesen der Register verwendet werden konnen. 

Beispielsweise kann JTAG gewahlt werden und der DB tiber die- 
ses Verfahren ggf. auch als externes seperates und evtl. auch 
marktiibliches Gerat (z. B. Firma Hitex, Karlsruhe) ange- 
schlossen sein. 

25 

Da bevorzugt auf samtliche Register, oder zumindest eine er- 
heblich Anzahl derer, durch den Debugger schreibend und/oder 
lesend zugegriffen werden kann, kann optional und bevorzugt 
ein wesentlicher Teil der (seriellen) Verkettung der Register 
30 zu Testzwecken (Scan-Chain) fur die Produktionstests des 

Chips ent fallen. Die Scan-Chain wird normalerweise dafur ver- 
wendet, urn alle Register innerhalb eines Chips wahrend der 
Produktionstests mit Testdaten vorladen zu konnen und/oder 
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die Inhalte der Register zu Testzwecken wieder zuriickzulesen. 
Das Vorladen und/oder Zurucklesen geschieht dabei typischer- 
weise durch Testsysteme (z.B. SZ Testsysteme, Araerang) 
und/oder gemali den in der DE 197 57 200.6-33 beschriebenen 

5 Verfahren. Die Scan-Chain benotigt dazu einen zusatzlichen 
nicht unerheblichen Hardware- und Flachenaufwand fur jedes 
Register. Dieser kann nunmehr, zumindest fur die Register, 
die debugbar sind, entfallen, wenn - wie erf indungsgemafl vor- 
geschlagen - die Produktionstestanlagen fiber geeignete 

10 Schnittstellen (z.B. parallel, seriell, JTAG, etc.) Zugriff 
auf die Register erhalten. 



2.2.2 Anhalten Oder Verlangsamen des Taktes 

15 Durch das Auftreten von Bedingung und/oder Vorbedingung kann 
der Takt entweder angehalten oder verlangsamt werden, urn hin- 
reichend Zeit zum Auslesen zur Verfugung zu stellen. Ausge- 
lost wird dieser Debugbeginn insbesondere entweder direkt 
durch eine PAE-, die die (Vor) Bedingung (en) berechnete oder 

20 durch eine ubergeordnete Einheit (z. B. Ladelogik/CT, Host- 
prozessor) aufgrund beliebiger Aktionen, beispielsweise durch 
die Information, daft an einer PAE eine (Vor ) Bedingung auftrat 
und/oder durch eine Aktion innerhalb des DebugProzessors 
und/oder durch ein beliebiges Programm und/oder eine beliebi- 

25 ge externe/periphere Quelle. Zum Informieren stehen Trigger- 
mechanismen entsprechend P 44 16 881.0-53, DE 196 51 075.9- 
53, DE 197 04 728.9, DE 198 07 872.2, DE 198 09 640.2, DE 100 
28 397.7 zur Verfugung. Alternativ kann beim Debuggen der 
Takt generell verlangsamt werden. Sollen nur Arrayteile de- 

30 buggt werden, kann eine partielle Heruntertaktung vorgesehen 
werden. 
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Sofern der Takt verlangsamt wird, muss durch den Debugprozes- 
sor innerhalb des verlangsamten Zyklus des Verarbeitungstak- 
tes alle relevante Debug-Inf ormation aus den PAEs ausgelesen 
werden. Dazu ist es sinnvoll und bevorzugt, den Takt nur par- 
5 tiell zu verlangsamen, also den Arbeitstakt zu senken oder 
anzuhalten, aber den Takt fur den Ausleseraechanismus weiter 
fortzufahren. Des weiteren ist es sinnvoll und bevorzugt, ge- 
nerell die Register zum Datenerhalt mit Takt zu versorgen. 

10 Nach dem Anhalten des Taktes kann ein Single-Step Modus rea- 
lisiert werden, d.h. der Debugprozessor halt den Verarbei- 
tungstakt so lange an, bis er alle Debug-Inf ormation ausgele- 
sen hat. Danach startet er den Verarbeitungstakt wieder fur 
einen Zyklus und halt ihn erneut bis nach dem Auslesen aller 

15 relevanten Debug-Inf ormationen an. 

Der Auslesetakt und der Takt des Debug-Prozessors sind bevor- 
zugt unabhangig vom Verarbeitungstakt der PAEs, so daJi die 
Datenverarbeitung vom Debugging und insbesondere Auslesen der 
20 Debug-Inf ormation getrennt ist. 

Hardwaretechnisch wird das Anhalten oder Verlangsamen des 
Taktes durch Methoden nach dem Stand der Technik, wie bei- 
spielsweise Gated-Clocks und/oder PLLs und/oder Teiler oder 

25 andere Verfahren erreicht. Diese Mittel werden bevorzugt an 
geeigneten Stellen (Knoten) innerhalb des Clock-Trees einge- 
fiigt, so dafi eine globale Taktsteuerungen der jeweils tiefer- 
liegenden Zweige realisierbar ist. Die Heruntertaktung nur 
von ausgewahlten Arrayteilen ist in den unter Bezug genomme- 

30 nen Anmeldungen des vorliegenden Anmelders offenbart. 

Besonders bevorzugt ist das Versenden einer Taktsteuer- 
Inf ormation von einer ubergeordneten Einheit (z.B. Ladelo- 
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gik/CT, Hostprozessor) an samtliche bzw. samtliche zu debug- 
genden PAEs . Dies kann bevorzugt iiber das Konf igurationsbus- 
system erfolgen. Die Taktsteuerinf orraation wird dabei typi- 
scherweise gebroadcastet iibertragen, d.h. alle PAEs erhalten 
5 dieselbe Information. 



Beispielsweise konnen folgende Taktsteuerinf ormationen imple- 
mentiert sein: 



STOP 
SLOW 
STEP 



15 STEP (n) : 



Der Arbeitstakt wird angehalten. 
Der Arbeitstakt wird verlangsamt . 

Exakt ein Verarbeitungsschritt (Single Step Modus) 
wird ausgefiihrt und dann der Arbeitstakt wieder an- 
gehalten . 

n Verarbeitungsschritte werden ausgefiihrt und dann 
der Arbeitstakt wieder angehalten. 
Der Arbeitstakt lauft normal weiter. 



Es soli insbesondere erwahnt sein, dass das Verfahren der 
20 Taktabschaltung und/oder Verlangsamung ebenso eingesetzt wer- 
den kann, um den Stromverbrauch zu reduzieren. Sofern tempo- 
rar keine Rechenleistung benotigt wird, kann ein "Sleepmode" 
beispielsweise durch das Abschalten des Arbeitstaktes (STOP) 
oder durch spezielle Befehle (SLEEP) realisiert werden. Wird 
25 nicht die voile Rechenleistung benotigt, kann der Takt durch 
die Verwendung von SLOW verlangsamt werden und/oder temporar 
durch STEP(n) ausgesetzt werden. Insoweit ist das Verfahren 
optional und/oder zusatzlich zu den in der DE 102 06 653.1 
beschriebenen Verfahren zur Reduzierung der Verlustleistung 
30 einsetzbar. 



Ein Problem des Broadcastings von Taktsteuerinf ormationen ist 
die Obertragungszeit des Broadcastes durch das Array aus 
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PAEs. Die Ubertragung kann bei hoheren Taktf requenzen nicht 
innerhalb eines Arbeitstaktes erfolgen. Es ist aber zwingend 
notwendig, dass samtliche PAEs zur gleichen Zeit auf die 
Taktsteuerinf ormationen reagieren. Bevorzugt wird die Takt- 
5 steuerinf ormation daher uber ein gepipelintes Bussystera ahn- 
lich des in DE 100 28 397.7 beschriebenen CT-Bussystems iiber- 
tragen. Weiterhin wird ein Zahlenwert (LATVAL) den Taktsteue- 
rinf ormationen hinzugefugt der gleich oder grofier der maxima- 
len Lange der Pipeline des Bussystems ist. In jeder Pipeli- 

10 nestufe wird taktweise der Zahlenwert dekrementiert (Subtrak- 
tion von 1) . Jede PAE, die die Taktsteuerinf ormation erhalt, 
dekrementiert im weiteren den Zahlenwert mit jedem Takt. Da- 
mit ist sichergestellt, dass der Zahlenwert in dem gepipelin- 
ten Bussystem und den PAEs , die die Taktsteuerinf ormation be- 

15 reits empfangen haben, immer exakt gleich ist. Erreicht der 
Zahlenwert den Wert 0, ist sichergestellt, daft alle PAEs die 
Taktsteuerinformation erhalten haben. Jetzt tritt die Takt- 
steuerinf ormation in Kraft und das Verhalten des Taktes wird 
entsprechend modif iziert . 

20 

Durch das beschriebene Verfahren entsteht eine weitere La- 
tenzzeit (Latency). Diese kann beispielsweise durch die nach- 
folgend beschriebene Registerpipeline zusatzlich abgefangen 
werden, oder, wie besonders bevorzugt, durch die Definition 
25 der (Vor) Bedingung abgefangen werden, indem die (Vor)Be- 

dingung soweit vorgesetzt wird, daJi die Latenzzeit bereits 
berucksichtigt ist. 

Es soil besonders erwShnt werden, daft die Latenzzeit im Sin- 
30 gle-Step Modus vernachlassigbar ist, da sie nur bei der Ab- 
schaltung es Taktes (STOP) eine Rolle spielt . Da der Befehl 
STEP immer nur exakt einen Schritt ausfiihrt, kommt es wahrend 
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des Single-Step Betriebes durch keinerlei Verfalschung (Ver- 
zogerung) der Debugdaten durch die Latenzzeit. 

5 2.2.3 Registerpipeline zum Ausgleichen der Latency 

Bei hoheren Betriebsf reguenzen kann es zu einer Latenzzeit 
zwischen dem Erkennen des Debugbeginns und dem Anhalten oder 
Verlangsamen des Taktes kommen. Diese Latenzzeit ist exakt 
vorherbestimmbar, da die Position der verzogernden Register 

10 in der VPU durch Hardware und/oder den zu debuggenden Algo- 
rithmus definiert und durch den Debugger daher exakt bere- 
chenbar ist. 

Durch die Latenzzeit verschieben sich jedoch die dem Debug- 
15 Prozessor zur Verfugung gestellten Inf ormationen derart, daft 
nicht mehr die korrekten Debuginf ormationen ausgelesen werden 
konnen. Bevorzugt wird dies durch ein entsprechendes Festle- 
gen der (Vor ) Bedingung durch den Programmierer gelost. Optio- 
nal kann durch das Einfugen einer mehrstufigen Registerpipe- 
20 line, die die Debuginf ormation in jedem Takt um ein Register 
weiter ubertragt, der Debugprozessor auf so viele Takte an 
Debuginformationen zuriickgreif en, wie die Registerpipeline 
lang ist. Die Lange der Registerpipeline ist so auszulegen, 
daft sie der maximal zu erwartenden Latenz entspricht. Auf- 
25 grund der exakten Berechenbarkeit der Latenzzeit ist es nun- 
mehr dem Debug-Programm moglich, die zeitlich korrekte, rele- 
vante Debug-Inf ormation aus der Registerpipeline auszulesen. 

Ein auftretendes Problem bei der Verwendung von Registerpipe- 
30 lines ist, daft diese verhaltnismafiig lang und damit, bezogen 
auf die fur die Realisierung notwendige Siliziumf lache, teuer 
sind. 
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2 . 3 Sichtbare Debug-Inf ormationen 

Bei dieser Methode wird im wesentlichen nach Auftreten der 
5 (Vor) Bedingung debugt, da erst danach der Takt verlangsamt 
Oder angehalten wird und das Auslesen der Debug-Inf ormation 
erfolgt. Debug-Inf ormationen, die vor dem Auftreten der 
(Vor) Bedingung liegen, sind daher zunachst nicht sichtbar. 

10 Es ist jedoch, wenngleich auch unter Verlust an Arbeitslei- 
stung, moglich eine VPU sofort vom Start einer Applikation an 
mit verlangsamten Takt oder Single-Step-Modus zu betreiben. 
Vom Start an werden die relevanten Debug-Inf ormationen vom 
Debug-Prozessor ausgelesen. 

15 

3. Methode B 

3 . 1 Grundprinzip 

20 

Relevante Debug-Inf ormationen aus den Speichereinheiten, die 
gemafl P 44 16 881.0-53, DE 196 54 846.2-53, DE 199 26 538.0, 
DE 101 39 170.6 und deren Zusatzanmeldungen, DE 101 10 530.4 
die Anwendungsdaten und Zustande eines bestimmten Arbeits- 

25 schrittes beinhalten, werden an das Debug- Programm ubertra- 
gen. Diese Speichereinheiten, nachfolgend auch Arbeitsspei- 
cher genannt, arbeiten im Maschinenmodell nach der P 44 16 
881.0-53, DE 196 54 846.2-53, DE 101 39 170.6 und deren Zu- 
satzanmeldungen, DE 199 26 538.0, DE 101 10 530.4 quasi als 

30 Register zur Speicherung von Daten, die innerhalb eines Kon- 
f igurationszykluses im PA oder Teilen des PAs berechnet wur- 
den. Es wird insbesondere auf die Patentanmeldung DE 101 39 
170.6 und deren Zusatzanmeldungen verwiesen, in der die Ver- 
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wendung der Speichereinheiten als Register (REG) zur Reali- 
sierung eines Prozessormodells detailliert beschrieben ist. 
Die DE 101 39 170.6 und deren Zusatzanmeldungen sind zu Of- 
f enbarungszwecken vollumf anglich eingegliedert . Eine Spei- 
5 chereinheit besteht dabei aus einer beliebigen Anordnung und 
Hierarchie von unabhangigen und abhangigen Speichern. Es ist 
moglich, gleichzeitig raehrere unterschiedliche Algorithmen 
auf dem PA (Processing Array) auszufiihren, die dann unter- 
schiedliche Speicher verwenden. 

10 

Wesentlich fur die Anwendung dieser Methode ist, daii Daten 
und/oder algorithmisch relevante Zustande in die den PAEs zu- 
geordneten Speichereinheiten abgelegt sind, wobei eine Spei- 
chereinheit jeweils zumindest derart dimensioniert ist, dafi. 
15 alle relevanten Daten und/oder Zustande eines Zyklus gespei- 
chert werden konnen; hierbei kann die Lange eines Zyklus 
durch die Grblie der Speichereinheit bestimmt sein und ist es 
bevorzugt .auch (vgl. DE 196 54 8 4 6.2-53) . Mit anderen Worten 
wird die Zykluslange der Hardware angepalit. 

20 

Unterschiedliche Daten und/oder Zustande werden derart in die 
Speichereinheiten gespeichert, daG diese eindeutig dem Algo- 
rithmus zugeordnet werden konnen. Dadurch kann der Debugger 
die relevanten Daten und/oder Zustande (Debug-Inf ormation) 
25 eindeutig identif izieren. 

Die relevanten Debug-Inf ormationen konnen - insbesondere auch 
vorab - durch den Programmierer innerhalb des Debug-Pro- 
grammes festgelegt werden. Diese Debug-Inf ormationen werden 
30 aus den Speichereinheiten ausgelesen. Dazu stehen unter- 
schiedliche Methoden zur Verfugung; einige Moglichkeiten wer- 
den nachfolgend naher beschrieben. Nach dem Auslesen aller 
relevanter Debug-Inf ormationen wird der nachste Konfigurati- 
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onszyklus ausgefuhrt und erneut die relevanten Debug-Infor- 
mationen ausgelesen. Dies wiederholt sich so lange, bis der 
Programmierer/Debugger den Debug-Vorgang abbricht. 

5 Mit anderen Worten werden die relevanten Daten und/oder Sta- 
tus informationen nicht taktweise, sondern konf igurationsweise 
an den Debugger ubertragen. Dies geschieht aus den Spei- 
chereinheiten, die mit den Registern einer CPU vergleichbar 
sind. 

10 

3 . 2 Unterstutzung durch die Hardware 

Wesentlich fur die Funktionsweise des Debuggers ist die Mog- 
15 lichkeit, durch die CT oder einen anderen extern angeschlos- 
senen Prozessor (im Folgenden DebugProzessor (DB) genannt) , 
die beispielsweise auch interne (n) Arbeitsspeicher der VPU zu 
lesen. Eine derartige Moglichkeit ist z.B. durch den AnschluB 
der CT an die Arbeitsspeicher zura Vorladen und Lesen der Da- 
20 ten und/oder durch die in der DE 199 26 538.0 beschriebene 

Verfahren zum Herausschreiben der internen Speicher an exter- 
ne Speicher gegeben. In einer mogliche Ausgestaltung kann auf 
Arbeitsspeicher durch verschieden Verfahren nach dem Stand 
der Technik (z.B. Shared Memory, Bank Switching) derart vom 
25 DebugProzessor zugegriffen werden, dass der Datenaustausch 

mit dem DB weitestgehend unabhangig von einer weiteren Daten- 
verarbeitung in der VPU erfolgen kann. 

In einer moglichen Ausgestaltung kann z. B. entsprechend Me- 
30 thode A durch eine oder mehrere der vorstehend beschriebenen 
Mafinahmen der Takt der VPU zum Auslesen der Speicher gegebe- 
nenfalls entweder entsprechend verlangsamt oder angehalten 
werden und/oder gegebenenf alls im Single-Step-Modus betrieben 
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werden. Dabei kann je nach Iraplementierung der Arbeitsspei- 
cher, z. B. beim Bank-Switch-Verf ahren, auf einen besonderen 
Eingriff in den Takt verzichtet werden. Typischerweise ge- 
schieht das Anhalten oder Verlangsamen des Taktes nach Metho- 
5 de B und das Auslesen und/oder Kopieren und/oder Umschalten 
der Arbeitsspeicher nur, wenn ein Datenverarbeitungszyklus 
bzw. Konf igurationszyklus beendet ist. 

Mit anderen Worten ist ein wesentlicher Vorteil von Methode 
10 B, dass keine besondere Unterstutzung durch die Hardware er- 
forderlich ist. 

In einer moglichen Ausgestaltung mufi> ein DB lediglich Zugriff 
auf die Arbeitsspeicher besitzen. In einer besonders zu be- 
15 vorzugenden Ausgestaltung geschieht der Zugriff auf die Ar- 
beitsspeicher durch eine geeignete Konf iguration der VPU, die 
dadurch die Arbeitsspeicher selbstandig und ohne Modifikation 
ausliest und an einen DB ubertragt . 

20 

3.3 Zugriff auf Debug-Inf ormation 

In der P 44 16 881.0-53, DE 196 54 846.2-53, DE 101 39 170.6, 
DE 199 26 538.0 sind Datenverarbeitungsverf ahren beschrieben, 

25 bei denen zyklisch eine Menge an Operationen auf einen rekon- 
f igurierbaren Datenverarbeitungsbaustein abgebildet werden. 
In jedem Zyklus wird eine Mehrzahl von Daten berechnet, die 
von einer peripheren Quelle und/oder einen internen/externen 
Arbeitsspeicher stairanen und an eine periphere Quelle und/oder 

30 einen internen/externen Arbeitsspeicher geschrieben werden. 

Dabei konnen jeweils unterschiedliche und/oder vor allem meh- 
rere unabhangige Arbeitsspeicher gleichzeitig verwendet wer- 
den. Beispielsweise konnen in diesem Datenverarbeitungsver- 
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fahren die Arbeitsspeicher Oder ein Teil der Arbeitsspeicher 
als Registersatz dienen. 

Nach der DE 101 39 170.6 und der DE 199 26 538-0 werden dabei 
5 samtliche Daten und Zustande, die fur die weitere Datenverar- 
beitung relevant sind, in die Arbeitsspeicher abgelegt 
und/oder aus selbigen gelesen. In einem bevorzugten Verfahren 
werden fur die weitere Datenverarbeitung irrelevante Zustande 
nicht gespeichert. 

10 

Die Unterscheidung zwischen relevanten und irrelevanten Zu- 
standen soil an folgendem Beispiel aufgezeigt werden, es soli 
zu Of f enbarungszwecken dabei insbesondere auf die Ausfiihrun- 
gen in der DE 101 39 170.6 verwiesen werden: 

15 

Die Zustandsinformation eines Vergleichs ist beispielsweise 
fur die weitere Verarbeitung der Daten wesentlich, da dieser 
die auszufiihrenden Funktionen bestimmt. 

20 Ein sequenzieller Dividierer entsteht beispielsweise durch 
Abbildung eines Divisionsbef ehles auf eine Hardware, die nur 
die sequenzielle Division untersttitzt. Dadurch entsteht ein 
Zustand, der den Rechenschritt innerhalb der Division kenn- 
zeichnet. Dieser Zustand ist irrelevant, da fur den Algorith- 

25 mus nur das Ergebnis (also die ausgefiihrte Division) erfor- 
derlich ist. In diesem Fall werden also lediglich das Ergeb- 
nis und die Zeitinf ormation (also die Verf iigbarkeit ) beno- 
tigt. 

30 Die Zeitinf ormation ist beispielsweise in der VPU-Technologie 
nach P 44 16 881.0-53, DE 196 51 075.9-53, DE 199 26 538.0 
durch das RDY/ACK Handshake erhaltlich. Hierzu ist jedoch be- 
sonders anzumerken, dafc das Handshake ebenfalls keinen rele- 
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vanten Zustand darstellt, da es lediglich die Gultigkeit der 
Daten signalisiert, wodurch sich wiederum die verbleibende 
relevate Information auf die Existenz gultiger Daten redu- 
ziert . 

5 

In der DE 101 39 170.6 wird eine Unterscheidung zwischen lo- 
kal und global relevanten Zustanden aufgezeigt: 

lokal: Der Zustand ist nur innerhalb einer einzigen abge- 
10 schlossenen Konf iguration relevant. Daher muli der Zustand 
nicht zwingend gespeichert werden. 

global: Die Zustandsinf ormation wird fur mehrere Konfigura- 
tionen benotigt. Der Zustand muli gespeichert werden. 

15 Es ist nunmehr denkbar, daft der Programmierer einen lokal re- 
levanten Zustand debuggen will, der nicht in den Speichern 
abgelegt ist. In diesem Fall kann die Applikation dahingehend 
modifiziert werden, dafi eine Debug-Konf iguration entsteht 
(Equivalent zum Debug-Code von Prozessoren) , die eine Modifi- 

20 kation zum "normalen" Code der Applikation derart aufweist, 
daft dieser Zustand zusatzlich in die Speichereinheit ge- 
schrieben und damit dem Debugger zur Verfiigung gestellt wird. 
Dadurch entsteht eine Abweichung zwischen Debug-Code und tat- 
sachlichem Code, die zu einem unterschiedlichen Verhalten der 

25 Codes fuhren kann. 

In einer daher besonders bevorzugten Ausfiihrung wird keine 
Debug-Konf iguration verwendet . Vielmehr wird die zu debuggen- 
de Konf iguration derart terminiert, dass die fur Debugging- 
30 zwecke zusatzlich erf orderlichen Daten die Terminierung uber- 
dauern, d.h. weiterhin gultig in den entsprechenden Speicher- 
stellen (REG) (z.B. Register, Zahler, Speicher) verbleiben. 
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Wenn die zu debuggende Konf iguration derart terminiert wird, 
dali die fiir Debugging-Zwecke zusatzlich erf orderlichen Daten 
die Terminierung uberdauern, ist es moglich, ein Debuggen 
einfach dadurch durchzuf iihren, daft nicht die nachste, bei 
5 normalem Programmablauf erforderliche Konf iguration geladen 
wird, sondern stattdessen eine Konf iguration, uber welche die 
zu den Debugging-Zwecken erf orderlichen Daten in die Debug- 
Einheit bzw. das Debug-Mittel ubertragen werden. Es sei dar- 
auf hingewiesen, daft bei einem solchen Debuggen auch im spa- 

10 teren Ablauf des Programmes stets die zu Debug-Zwecken erfor- 
derlichen Daten mit abgespeichert werden konnen, wodurch si- 
chergestellt ist, dafi das spater ausgefiihrte Programm in ex- 
akt der Weise einem Debug-Prozefi unterworfen wurde wie erfor- 
derlich. Nach Auslesen der Debug-Inf ormation durch eine dedi- 

15 zierte Debug-Konf iguration kann dann mit der normalen Pro- 
grammausfuhrung fortgefahren werden. 

Eine Konf iguration wird geladen, diese verbindet die REG in 
geeigneter Weise und definierter Reihenfolge mit einem oder 
20 mehreren globalen Speicher(n), auf die der DB Zugriff hat 
(z.B. Arbeitsspeicher) . 

Vorgeschlagen wird also, daft eine Konf iguration geladen wird, 
diese die REG in geeigneter Weise verbindet und in definier- 
25 ter Reihenfolge mit einem oder mehreren globalen Speichern 
verbindet, auf die der DB Zugriff hat (z. B. Arbeitsspei- 
cher) . 

Die Konf iguration kann beispielsweise Adressgeneratoren ver- 
30 wenden, urn auf den/die globalen Speicher zuzugreifen. Die 

Konf iguration kann beispielsweise Adressgeneratoren verwen- 
den, um auf als Speicher ausgestaltete REG zuzugreifen. Ent- 
sprechend der konf igurierten Verbindung zwischen den REG wer- 
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den die Inhalte der REG in einer definierten Reihenfolge in 
den globalen Speicher geschrieben, wobei die jeweiligen 
Adressen von Adressgeneratoren vorgegeben werden. Der Adress- 
generator generiert die Adressen fur den/die globalen Spei- 
cher (n) derart, dafi die beschriebenen Speicherbereiche (DEBU- 
GINFO) der entfernten zu debuggenden Konf iguration eindeutig 
zugeordnet werden konnen. 

Das Verfahren entspricht dem Kontext-Switch in DE 102 0 6 
653.1 und DE 101 39 170.6, die zu Of f enbarungszwecken vollum- 
fanglich eingegliedert sind. 

Der DB kann nunmehr auf die Daten innerhalb eines ihm zugang- 
lichen Speicherbereich.es (DEBUGINFO) zugreifen. Soil das De- 
bugging mittels eines Single-Step Verfahrens durchgefuhrt 
werden, kann nach jedem single step einer zu debuggenden Kon- 
figuration ein Kontext-Switch derart durchgefuhrt werden, 
dass samtliche Daten erhalten bleiben und die zu debuggende 
Information aus den REG in einen Arbeitsspeicher geschrieben 
wird. Sodann wird wiederum unter Erhalt der Daten die zu de- 
buggende Konf iguration wieder konfiguriert und fur einen wei- 
teren single step ausgefiihrt. Dies geschieht fur jeden zu de- 
buggenden single step der zu debuggenden Konf iguration. Auf 
die Moglichkeit eines Debugging unter Verwendung der als „Wa- 
ve-Rekonf iguration" bekannten Prinzipien sei hingewiesen. 

3.4 Sichtbare Debug-Informationen 

Ein Debuggen vor der (Vor ) Bedingung kann vergleichsweise ein 
fach und ohne groJie Perf ormance-Verluste durchgefuhrt werden 
da die benotigten Debug-Informationen in Arbeitsspeichern 
verftigbar sind. Durch das Ubertragen der Arbeitsspeicher in 
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andere Speicherbereiche, auf die der DB bevorzugt direkten 
Zugriff hat, kann die Debug-Inf ormation einfach sicherge- 
stellt werden. Eine noch schnellere Methode ist, die Arbeits- 
speicher durch ein Bank-Switching-Verf ahren (nach dem Stand 
5 der Technik) derart zwischen den einzelnen Konf igurationen 
.umzuschalten, daft die Debug-Inf ormation in einer jeweils neu- 
en Bank liegt. Das Umschalten kann sehr zeitoptimierend, im 
Optimalfall sogar ohne Auswirkung auf die Verarbeitungslei- 
stung erfolgen. 

10 

Es ist bereits offenbart worden, dafi bei einer VPU Daten 
blockweise in einen Speicherbereich ubertragen werden konnen. 
Dieser kann auch aufterhalb des eigentlichen PA liegen 
und/oder einen Dual-Ported-RAM oder dergleichen aufweisen, so 
15 daii es moglich ist, auf die eingeschriebene Information von 
aufien leicht zuzugreifen. 



4 . Funktionsweise des Debuggers 

20 

Das Debugger-Programm selbst kann auf einem DB aulierhalb des 
PAs ablaufen. Alternatiy dazu kann eine VPU selbst den DB 
darstellen, entsprechend der Methoden, die bei Prozessoren 
angewendet werden. Dazu kann ein Task- oder Kontextswitch 

25 (SWITCH) entsprechend den Ausfiihrungen in PACT11 ausgefuhrt 
werden. Die Debuginf ormationen des zu debuggenden Programmes 
werden bei einem SWITCH zusammen mit den relevanten Daten ge- 
sichert und das Debugger Programm geladen, das die Inf orma- 
tionen auswertet und/oder interaktiv mit dem Programmierer 

30 verarbeitet. Danach wird erneut ein SWITCH durchgefuhrt (bei 
welchem die relevanten Inf ormationen des Debuggers gesichert 
werden) und das zu debuggende Programm wird weitergef Uhrt . 
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Es sei auch erwahnt, dali als Debugger ein Prozessor-Teil- 
bereich vorgesehen werden kann. 

Die Debug-Inf ormation wird vom Debugger entsprechend Methode 
5 A und/oder B gelesen und in einen von der Datenverarbeitung 
separaten Speicher und/oder Speicherbereich gespeichert, auf 
den der DB bevorzugt direkten Zugriff besitzt. Durch das De- 
bugger- Programm werden die Breakpoints und (Vor) Bedingungen 
definiert. Ebenfalls kann das Debugger- Programm die Kontrolle 
10 iiber die Ausfuhrung der Applikation, insbesondere den Ausfiih- 
rungsstart und das Ausf uhrungsende ubernehmen. 

Der Debugger stellt dem Programmierer eine geeignete Arbeits- 
umgebung zur Verfugung mit ggf. graphischer Oberflache. In 

15 einer besonders bevorzugten Ausfuhrung ist der Debugger in 

eine komplexe Entwicklungsumgebung integriert und tauscht mit 
dieser Daten und/oder Steuerinf ormation aus. Insbesondere 
kann der Debugger die aus den Arbeitsspeichern gelesenen Da- 
ten zur beliebigen Weiterverarbeitung auf einen Datentrager 

20 (Festplatte, CDROM) speichern und/oder innerhalb eines Netz- 
werkes (wie Ethernet) ablaufen. 

Der erf indungsgemafie Debugger kann zudem gemali DE 101 2 9 
237.6-53 innerhalb einer Entwicklungsumgebung mit anderen 

25 Werkzeugen und insbesondere auch Debuggern kqmmunizieren; wo- 
bei in einer bevorzugten Ausgestaltung die Steuerung und/oder 
Definition der Debugparameter von einem anderen Debugger aus 
ubernommen werden kann. Ebenso kann der Debugger die von ihm 
generierte Debug-Inf ormation einem anderen Debugger zur Ver- 

30 ftlgung stellen und/oder von diesem dessen Debug-Inf ormation 
erhalten. 
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Insbesondere das Feststellen des Auftretens von Breakpoints 
und/oder (Vor ) Bedingung ist durch einen anderen Debugger bzw. 
den Einheiten, die dieser andere Debugger debugt, durchfuhr- 
bar. Der erf indungsgemaJie Debugger und die VPU reagieren dann 
5 entsprechend. 

Der andere Debugger kann insbesondere der Debugger eines mit 
einer VPU gekoppelten anderen Prozessors (CT, bzw. ARC bei 
Chameleon, Pentium, AMD usw.) sein. 

10 

Insbesondere kann der andere Debugger auf einem der VPU zuge- 
ordneten und/oder gekoppelten Prozessor ablaufen und/oder der 
zugeordnete Prozessor der DB sein, beispielsweise eine CT 
bzw. ARC bei Chameleon. In einer besonders bevorzugten Ausge- 
15 staltung kann der zugeordnete Prozessor ein Host-Prozessor 
sein, wie beispielsweise in der 60/317,876 und/oder der DE 
102 06 856.9 beschrieben. 

20 5 . Bewertung der Methoden 

Die Methode A ist erheblich zeit- und ressourcenintensiver 
als die Methode B, bei der kaum zusatzliche Hardware erfor- 
derlich ist und zudem ggf. das zeitauf wendige Auslesen der 
25 Debug-Inf ormation vom Start der Applikation an entfallt. Da- 
her ist Methode B grundsatzlich vorzuziehen. Fur Compiler 
nach DE 101 39 170.6 und deren Zusatzanmeldungen ist die Me- 
thode B eindeutig zu praferieren. 

30 Es wurde erkannt, daft insbesondere die Verwendung beider Me- 
thoden A und B gemeinsam zu den besten und transparentesten 
Debuggingergebnissen f iihrt . Insbesondere kann je nach Tiefe 
des zu debuggenden Fehlers zunachst unter Zuhilfenahme der 
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schnellen Debuggingmethode B debuggt werden und nach hinrei- 
chende Lokalisierung des Fehlers sodann per Methode A die De- 
tails in der "Tiefe" analysiert werden. 

6. Mixed Mode Debugger 

Bei der Anwendung der besonders bevorzugten Methode B kann es 
zu dem Problem kommen, dass die in den Speichern befindliche 
sichtbare Information nicht hinreichend ist. 

Typischerweise kann ein detaillierteres Debugging folgender- 
massen erfolgen: 

a) Die sichtbare Debuginf ormation ( PRE INFO) vor der Konfigu- 
ration einer einen Breakpoint enthaltenden Konf iguration 
wird gesichert. Bei Auftreten eines Fehlers bei dem Bre- 
akpoint wird die dann sichtbare Debuginf ormation (POSTIN- 
FO) gesichert. Basierend auf der PRE INFO Information wird 
ein Software-Simulator gestartet, der die zu debuggen- 
de(n) Konf iguration (en) simuliert. Der Simulator kann da- 
bei jeden Wert innerhalb der PAEs "und der Bussysteme be- 
stimmen und (ggf . auch graphisch und/oder textuell) aus- 
geben, wodurch ein detaillierter Einblick in den Ablauf 
des Algorithmus zum Zeitpunkt des Auftretens des Fehlers 
erreicht wird. Insbesondere ist es moglich, die jeweils 
simulierten Werte mit den Werten von POSTINFO zu verglei- 
chen, urn Differenzen schnell zu erkennen. 

b) Die sichtbare Debuginf ormation vor einem Breakpoint wird 
gesichert. Bei Auftreten eines Breakpoints wird basierend 
auf dieser Information ein Sof tware-Visualisierer gestar- 
tet. Der zu debuggende Baustein wird nunmehr in einem 
Single-Step Verfahren betrieben, das das Auslesen samtli- 
cher relevanter Daten nach Methode A ermoglicht. Diese 
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Daten konnen nunmehr entweder direkt (ggf. auch graphisch 
und/oder textuell) ausgegeben werden und/oder an einen 
Simulator weitergeleitet werden, dessen Simulation sodann 
auf den detaillierteren Daten beruht, und danach wie be- 
kannt ausgegeben werden. 

6.1 Vorteile eines Mixed-Mode -Debuggers 

Der Mixed-Mode-Debugger ermoglicht die detaillierte Analyse 
der Ablaufe innerhalb eines Bausteines. Durch- die Moglichkeit 
gemafi Methode B, bis zu einem gesetzten Breakpoint mit voller 
Geschwindigkeit zu arbeiten und danach ggf. anzuhalten, zu 
verlangsamen und/oder ggf. in einen Single-Step-Modus zu ge- 
hen, wird das Debugging zeitef f izient , wodurch das Testen 
grofier Datenmengen und/oder komplexer Algorithmen ermoglicht 
wird. Das bevorzugte Aufsetzen eines Simulators nach dem Auf- 
treten des Breakpoints auf Basis der aktuellen Daten und Zu- 
stande ermoglicht einen genauen Einblick in die Hardware. So- 
fern der Zeitaufwand fur die Simulation zu hoch ist und/oder 
die 100% Obereinstimmung des Simulators mit der Hardware 
fraglich ist, ermoglicht das Zurticklesen von Daten im Single- 
Step-Modus nach Auftreten eines Breakpoints gemafi. Methode A 
oder entsprechend des Kontext-Switch Verfahrens nach DE 102 
06 653.1 und DE 101 39 170.6 ein 100% korrektes Debugging des 
Algorithmus und/oder auch der Hardware selbst. 

7 . Beschreibung der Figuren 

Figur 1 und 2 entsprechen der Patentanmeldung DE 101 39 
17 0.6. Die unterschiedlichen Ansatze der Methoden A und B 
wurden in die Figuren eingezeichnet (A, B) 
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Figur lb zeigt eine Representation des endlichen Automaten 
durch eine rekonf igurierbare Architektur nach P 44 16 881.0- 
53 und DE 196 54 846.2-53 (DE 196 54 846.2-53, Fig. 12-15). 
Das kombinatorischen Netz aus Figur la (0101) wird durch eine 
Anordnung von PAEs 0107 ersetzt (0101b) . Das Register (0102) 
wird durch einen Speicher (0102b) ausgefuhrt, der mehrere Zy- 
klen speichern kann. Die Ruckkopplung gemafi 0105 erfolgt 
durch 0105b. Die Eingange (0103b bzw. 0104b) sind Equivalent 
0103 bzw 0104. Der direkte Zugriff auf 0102b kann ggf. durch 
einen Bus durch das Array 0101b realisiert werden. Der Aus- 
gang 0106b ist wiederum Equivalent 0106. 

Figur 2 zeigt die Abbildung eines endlichen Automaten auf ei- 
ne rekonfigurierbare Architektur. 0201 (x) reprasentieren das 
kombinatorische Netz (das entsprechend Figur lb als PAEs aus- 
gestaltet sein kann) . Es existiert ein oder mehrere Speicher 
fur Operanden (0202) und ein oder mehrere Speicher fur Ergeb- 
nisse (0203) . Zusatzlich Daten Ein-/Ausgange gem. 0103b, 
0104b, 0106b) sind der Einfachheit halber nicht dargestellt. 
Den Speichern zugeordnet ist jeweils ein Adressgenerator 
(0204, 0205). 

Die Operanden- und Ergebnisspeicher (0202, 0203) sind physi- 
kalisch oder virtuell derart miteinander verkoppelt, daft bei- 
spielsweise die Ergebisse einer Funktion einer anderen als 
Operanden dienen konnen und/oder Ergebnisse und Operanden ei- 
ner Funktion einer anderen als Operanden dienen konnen. Eine 
derartige Kopplung kann beispielsweise durch Bussysteme her- 
gestellt werden oder durch eine (Re) Konf iguration, durch wel- 
che die Funktion und Vernetzung der Speicher mit den 0201 neu 
konfiguriert wird. 



WO 03/023616 



25 



PCT/DE02/03278 



Figur 3 zeigt eine mogliche schematische Struktur des Debug- 
gings nach Methode B. Es sei insbesondere beispielhaft auf 
die Figuren 19, 20, 21 der Patentanmeldung DE 199 26 538.0 
verwiesen, in welcher die Grundlage der Speicher beschrieben 
ist. Die DE 199 26 538.0 wird hiermit zu Of f enbarungszwecken 
vollumfanglich eingegliedert . 

0101b und 0102b ist wie bereits beschrieben dargestellt. Zu- 
satzlich ist eine externer Speichereinheit dargestellt 
(0302), der moglicherweise ahnlich DE 199 26 538.0 an 0102b 
angeschlossen (0307) sein kann. Es soil besonders darauf hin- 
gewiesen werden, dafi sowohl 0102b als auch 0302 externe oder 
interne Speichereinheiten sein konnen. Ebenfalls soil eine 
Speichereinheit als mindestes ein Register, eine Menge von 
Registern oder ein Speicher (RAM, Flash, o.a.) oder Massen- 
speicher (Festplatte, Band, o.a.) definiert sein. 

Die debuggende Einheit 0301 kann Breakpoints innerhalb 0101b 
setzen (0303), auf Basis derer der eigentliche Debug Vorgang 
ausgelost wird. Durch das Erreichen eines Breakpoints wird 
eine Information (0304) an 0301 gesendet, die den Debug Vor- 
gang startet; zugleich werden auch alle 0101b interenen Vor- 
kehrungen zum Debuggen (z.B. ein Anhalten und/oder Verlangsa- 
men des Taktes) ausgelost. Alternativ kann auch durch 0301 
die Information generiert und an 0101b gesendet werden. 
Ober 0305 und/oder 0306 kann 0301 auf die Daten und/oder Zu- 
stande aus dem Speicher 0102b und/oder dem Speicher 0302 zu- 
greifen. Der Zugriff kann zum Beispiel 

1. durch eine Speicherkopplung (Block-Move, d.h. kopieren 

der Speicher in einen anderen, von 0301 kontrollierten 

Bereich) , 
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2. durch eine Leitung (serielle oder parallele Leitung, 
iiber die ein oder mehrere Speicherbereich (e) ilbertragen 
wird/werden, z.B. JTAG) , 

3. Buskopplungen gleich welcher Art (die Speicher werden 

5 ahnlich eines DMA-Verf ahren arbitriert und von 0301 ver- 

arbeitet ) 
erf olgen. 

Als Beispiel wurde eine Figur aus der DE 199 26 538.0 ge- 
10 wahlt. Es soli ausdriicklich darauf hingewiesen werden, dali 

grundlegend jedes Speicherverf ahren und jede Speicher kopplung 
(Stack, Random- Ac cess, FIFO, usw.) entsprechend bearbeitet 
werden kann. 

15 Die Figuren 4a und 4b zeigen weitere moglichen Ausgestaltun- 
gen und wurden aus der Patentanmeldung DE 102 06 856.9 ent- 
nommen, die zu Of f enbarungszwecken vollumf anglich eingeglie- 
dert ist. 

20 Der Aufbau einer besonders bevorzugteri" VPU ist in Figur 4a 

dargestellt. Vorzugsweise hierarchische Konf igurationsmanager 
(CT's) (04 01) steuern und verwalten eine Anordnung von rekon- 
figurierbaren Elementen (PACs) (0402). Den CT's ist ein loka- 
ler Speicher fur die Konf igurationen zugeordnet (0403) . Der 

25 Speicher verfiigt weiterhin iiber ein Interface (0404) zu einem 
globalen Speicher, der die Konf igurationsdaten zur Verfugung 
stellt. Ober ein Interface (0405) sind die Konf igurationsab- 
lauft steuerbar. Ein Interface der rekonf igurierbaren Elemen- 
te (0402) zur Ablauf steuerung und Ereignisverwaltung (0406) 

30 ist vorhanden, ebenso ein Interface zum Datenaustausch 
(0407). Beipielsweise kann eine der CT's als DB agieren. 
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Figur 4b zeigt einen Ausschnitt aus einem beispielhaf ten CPU- 
System, beispielsweise einem DSP des Types C6000 von Texas 
Instruments (0451). Dargestellt sind Programmspeicher (0452), 
Datenspeicher (0453), beliebige Peripherie (0454) und EMIF 
(0455) . Uber einen Speicherbus (0456) und einen Peripheriebus 
(0457) ist eine VPU als Coprozessor integriert (0458) . Ein 
DMA-Kontroller (EDMA) (0459) kann beliebige DMA-Transfers, 
beispielsweise zwischen Speicher (0453) und VPU (0458) oder 
Speicher (0453) und Peripherie (0454) durchfuhren. In diesem 
Beispiel kann 0451 als DB arbeiten und insbesondere auch der 
erfindungsgemalie Debugger mit dessen Debugger gekoppelt 
und/oder in diesen integriert sein. 

Figur 5a zeigt einen beispielhaf ten Hardwareaufbau, der zum 
Debuggen von rekonf igurierbaren Prozessoren benutzt werden 
kann. Hierzu wird ein gepipelinter Konf igurationsbus 0501 
verwendet, ahnlich dem aus DE 100 28 397.7 bekannten. Die 
Pipeline ist uber mehrere Registerstuf en (0502) in horizonta- 
ler und/oder vertikaler Richtung aufgebaut, urn hohere Takt- 
frequenzen zu erreichen. Der gepipelihte Konf igurationsbus 
fuhrt zu den zu konf igurierenden Elementen (PAEs) (0503), um 
diese mit Konf igurationsdaten zu versorgen. 

Figur 5t> zeigt beispielhaft die erf orderliche Erweiterung ge- 
maft der vorliegenden Erfindung. Jede Registerstuf e (0502) de- 
krementiert den Zahlenwert (LATVAL) zum Ausgleich der Latenz- 
zeit um 1 (angedeutet durch -1) . Ebenso dekrementiert jede 
PAE (0503), die bereits eine Taktsteuerinf ormation erhalten 
hat, diese pro Takt um 1 (angedeutet durch -1/T) . Auf die 
PAEs und insbesondere deren internen Register kann nunmehr 
nicht nur schreibend, sondern auch lesend zugegriffen werden 
z.B. uber eine besondere Steuerleitung (RD) , um Debugdaten 
auszulesen. Zu schreibende und gelesene Daten durchlaufen in 
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diesem Beispiel das Bussystem durch das Array aus PAEs von 
links nach rechts und in der untersten Zeile in Riick- 
wartsrichtung. Der Konf igurationsbus ist weiterhin iiber Regi- 
sterstufen (0505) pipelineartig zuruckgef tihrt (0504) . In die- 

5 sem Beispiel kann eine iibergeordnete Einheit (CT/Ladelogik, 
Hostprozessor) (0506) ebenso lesend und schreibend auf den 
Bus . zugreif en, wie ein dediziertes Testinterf ace (0507). Das 
Testinterface kann einen eigenen Testkontroller aufweisen und 
insbesondere kompatibel zu einem oder mehrern marktgangigen 

10 Testschnittstellen sein (z.B. JTAG, Tektronix, Rhode&Schwarz, 
etc) . Die Auswahl der bussteuernden Einheit erfolgt iiber eine 
Multiplexer/Demultiplexer-Einheit (0508) . In (0509 in Klam- 
mern und kursiv dargestellt) oder vor den Einheiten 0506 und 
0507 kann eine Schaltung zur Ruckrechung der Herkunf tsadresse 

15 (0509) von Debugdaten, die iiber 0504 eintreffen, vorgesehen 
sein. Die Adressberechnungen innerhalb des aufgezeigten Sy- 
stems geschehen wie folgt: Zunachst wird die Adresse durch 

0506 oder 0507 am Bus 0501 angelegt. Die Adresse wird ahnlich 
der Verarbeitung der Zahlenwerte (LATVAL) zur Latenzberech- 

20 nung in jeder Registerstuf e (0502 und 0505) dekrementiert . 

Sobald die Adresse gleich 0 ist, wird die nach der Register- 
stuf e liegende PAE selektiert. In der nachf olgenden Register- 
stufe wird die Adresse negativ, so daB keine weiteren PAEs 
mehr aktiviert werden. Sofern Daten aus einer PAE gelesen 

25 werden, werden diese zusammen mit der Adresse zuriickiibertra- 
gen. Die Adresse wird dabei in jeder Registerstuf e weiter de- 
krementiert. Eine Riickrechnung in 0509 der bei 0506 und/oder 

0507 zusammen mit den Debugdaten eintref f enden. Adressen ist 
nunmehr durch eine einfache Addition moglich, indem die An- 

30 zahl der dekrementierenden Registerstuf en zu dem eintreffen- 
den Adresswert hinzuaddiert werden. Es soli angemerkt sein, 
dass die Registerstuf en 0502 in Figur 5b leicht unterschied- 
lich gegenuber den Registerstufen 0502 in Figur 5a ausgestal- 
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tet sind. In Figur 5b weisen diese namlich zusatzlich eine 
Schaltung (z.B. Multiplexer) zu Auswahl der weiterzuleitenden 
Daten auf, der entweder die Daten des Busses 0501 weiter- 
schaltet oder den Ausgang der zugeordneten PAE (0503) und so- 
5 rait die DebugDaten. Zur Ansteuerung der Schaltung kann das 
Auftreffen des Adresswertes gleich 0 dienen. 

Es wird nochmals darauf hingewiesen, dafi das dedizierte Te- 
stinterface (0507) den Industriestandards entspricht. Es kann 

10 zu Tests wahrend des Sof tware-Debug-Vorgangs eingesetzt wer- 
den und/oder zu Test wahrend des Zusammenbaus von Hardware- 
komponenten und -systemen (z.B. dem Zusammenbau der Schaltun- 
gen auf der Platine) und/oder zu Funktionstests des Halblei- 
terbausteins (Chips) im Rahmen der Halbleiterf ertigung . Ins- 

15 besondere dadurch kann die ubliche Scan-Chain zum Test der 

Register wahrend des Funktionstests des Halbleiters entfallen 
oder zumindest entsprechend minimiert werden, da dann nur die 
Register durch die Scan-Chain gefuhrt werden mussen, die 
nicht vora Bussystem (0501) ansteuerbar sind. 

20 

Ebenfalls wird besonders darauf hingewiesen, dali das in Figur 
5 erlauterte Verfahren keinesfalls auf die Anwendung bei Kon- 
f igurationsbussen beschrankt ist. Gewohnliche Datenbussysteme 
konnen ebenso zu den unterschiedlichen vorab aufgezahlten 

25 Test- und Debugging-Zeitpunkten und -arten verwendet werden. 
Insbesondere sei in diesem Zusammenhang auf das in der DE 197 
04 742.4 beschriebene Datenbussystem hingewiesen. Die DE 197 
04 742.4 ist hierzu zu Of f enbarungszwecken vollumf anglich 
eingegliedert . Die in Figur 5 beschriebenen Verfahren konnen, 

30 fur einen Ingenieur mit gewohnlichen technischen Kenntnissen 
leicht nachvollziehbar ebenso auf die DE 197 04 742.4 ange- 
wendet werden. 
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Ein Mischbetrieb unterschiedlicher Bussysteme, wie Konfigura- 
tionsbussystemen, Datenbussystemen nach DE 197 04 742.4 und 
gewohnlichen Datenbussystemen ist desweiteren grundsatzlich 
moglich. Dazu konnen mehrere Testinterf ace vorgesehen sein, 
oder wie technisch bevorzugt die Multiple- 

xer/Demultiplexerstufe (0508) auf eine Mehrzahl von Bussyste- 
men (n x 0501, n x 0504) ausgelegt werden. 

Abschliefiend soil noch besonders erwahnt sein, dass durch die 
Riickfuhrung des Bus systems nach Figur 5b auch die in die PAEs 
zu schreibenden Konf igurationsdaten zuriickgef iihrt werden. Un- 
ter Zuhilfenahme der Adressriickrechung (0509) und der zuriick- 
gefuhrten Statusleitung REJ, die nach DE 100 28 397.7, DE 198 
07 872.2, DE 196 54 593.5-53 eine Zuruckweisung der Konf igu- 
rationsdaten anzeigt, kann auf die Verwendung der Konfigura- 
tionszwischenspeicher-FIFOs nach DE 100 28 397.7 Figuren 8 
und 9 (0805, 0903) verzichtet werden, da deren Funktionalitat 
nunmehr vollumf anglich uber das beschriebene Bussystem abge- 
bildet wird. 
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Zustand, der nur innerhalb einer 
bestimmten Konf iguration relevant 
1st- 

Zustand, der in mehreren Konfigu- 
rationen relevant ist und zwi- 
schen den Konf igurationen ausge- 
tauscht werden muli. 

Zustand, der innerhalb eines Al- 
gorithmus zur korrekten Ausfiih- 
rung dessen benotigt wird und so- 
mit durch den Algorithmus be- 
schrieben ist und verwendet wird. 

Zustand, der fur den eigentlichen 
Algorithmus ohne Bedeutung ist 
und auch nicht ira Algorithmus be- 
schrieben ist, der jedoch von der 
ausfuhrenden Hardware implemen- 
tierungsabhangig benotigt wird. 
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Titel: Verfahren zum Debuggen rekonf igurierbarer 

Architekturen 



Patent anspriiche 

1. Verfahren zum Debuggen von rekonf igurierbarer Hardware, 
dadurch gekennzeichnet, daii samtliche notwendige Debug- 
information je Konf igurationszyklus in einen Speicher ge- 
schrieben werden, der dann vom Debugger ausgewertet wird. 

2. Verfahren nach dem vorhergehenden Anspruch, dadurch ge- 
kennzeichnet, dafi wahrend des Debug-Vorganges nach Auf- 
treten einer Debug-Bedingung, gemafi welcher Information 
iiber die zu debuggende Konf iguration benotigt wird, eine 
Konfiguration geladen wird, mittels welcher die in den 
Speicher geschriebenen Debug-Inf ormationen ausgelesen und 
insbesondere in eine Debug-Einheit oder Debug-Konf igura- 
tion geschrieben werden. 

3. Verfahren nach einem der vorhergehenden Anspriiche, da- 
durch gekennzeichnet, dafi eine zu debuggende Konfigurati- 
on vor dem Ablauf des Debugging derart verandert wird, 
dafi bei normaler, nicht-debuggender Ausfuhrung nicht er- 
forderliche Information in einem Speicher abgelegt wird. 

4. Verfahren nach einem der vorhergehenden Anspriiche, da- 
durch gekennzeichnet, dafi zum Auslesen die Taktfrequenz 
zumindest verlangsamt oder angehalten wird und/oder eine 
taktweise Abarbeitung der zu debuggenden Konfiguration 
Schritt fur Schritt erfolgt. 
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Verfahren nach einem der vorhergehenden Anspriiche, da- 
durch gekennzeichnet, daft die zu debuggende Konf iguration 
nach Auslesen der relevanten Information oder nach davor- 
liegender Information simuliert wird. 

Vorrichtung mit einem Feld konf igurierbarer Elemente, 
insbesondere grobgranularer logischer und/oder arithmeti- 
scher Einheiten sowie einem Debug-Mittel zum Debuggen von 
Programmen, Programmteilen oder auf dem Array auszufuh- 
renden komplexen Operationen, dadurch gekennzeichnet, daft 
das Debug-Mittel ein Speichermittel zur Speicherung von 
fiir das Debugging relevanten Inf ormationen wahrend oder 
am Ende eines Arbeitsschrittes des Feldes konf igurierba- 
rer Elemente umfaftt, wobei das Speichermittel zum Debug- 
ging auslesbar ist . 

Vorrichtung nach dem vorhergehenden Anspruch, dadurch ge- 
kennzeichnet, daft das Speichermittel als Dual-Ported-RAM 
mit einem ersten Eingang fur abzuspeichernde Information 
aus dem Prozessorf eld und einem zweiten Eingang zum Aus- 
lesen der Information in ein Analysemittel ausgebildet 
ist. 
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